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Subject! Priority Scheduler 
INTRODUCTION 

This document describes the functions and proposed implementation 
of a scheduler for Nultics which will allow more flexible 
administrative control of the allocation of the cpu time resource 
to system users and groups of users. 

It is not an objective of this proposal to attempt to achieve 
greater throughput in any numerical sense* However* it is an 
explicit objective that throughput of J obs deemed most valuable 
by a system administrator will be increased. To that extent* the 
value of Hultics as a computer utility is enhanced. Of course* 
every effort will be made to ensure the efficiency of the design 
and implementation of the priority scheduler. 

THE PROBLEM 

Currently* the Answering Service provides a mechanism (load 
control! for classifying users into groups* and giving each group 
a specified share of the system (by limiting the number of users 
from each group that may be logged in concurrently!. 

However* except for the setting of the per-process parameter* 
timax* no control over the rate of consumption of cpu resources 
by any user or group of users is provided. (Briefly stated* 
there is a parameter* ti» associated with each process* which is 
roughly proportional to the amount of cpu time used by the 
process since it last interacted. If the value of ti for a 
process ever exceeds timax* it is set to timax. The process with 
the lowest value of ti is always selected for eligibility.} In 
practice* the considerable advantage given to a process by a 
lower-than-norraal value of timax has prevented all processes but 
the Initializer (and sometimes Backup! from being given tlmax's 
lower than the default value. 

THE SOLUTION 

This NTB proposes that the scheduler allow the grouping of 
processes into work classes* and provide each work class with a 
guaranteed percentage of available cpu time. Conceptually* each 
work class will be assigned a virtual processor of 
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administrative!/ defined computational power, available to 
members of the appropriate work class on demand* Any cpu time 
not needed oy a work class will be made available to other work 
classes* and cannot be reclaimed at a later time. In this 
respect each virtual processor is like a real processori time 
unused is time lost forever. 

In its idealized form, the scheduler proposed here provides each 
work class with a specified computational power on an 
instantaneous basis. The idealized scheduler has a time constant 
(or integrating time) approaching zero seconds. The service and 
function provided by the idealized scheduler are known constants, 
not subject to being bent out of shape by previous transients in 
per-workc I ass loads. 

The actual scheduler will for reasons of system efficiency, 
scheduler efficiency and response, necessarily have a time 
constant on the order of several seconds. As an example, 
consider the time constant required to smoothly provide service 
to a work class which has been assigned 20 percent of a single 
cpu configuration and whose members are generally provided with 
an eligibility quantum of 2 seconds. If the scheduler functions 
correctly, some process in the work class will be given a two 
virtual second quantum every 10 virtual seconds, or approximately 
every 20 real seconds. This implies that in some way the 
scheduler must be integrating over the past 20 real seconds for 
such a work class. Averaging over a considerably shorter period 
would require significantly shorter quanta and result in 
Increased scheduler and paging overhead. Averaging over longer 
periods of time moves away from the idealized scheduler and 
toward a scheduler whose behavior is more dependent than 
necessary on the past history of the system. 



The ability to limit the number of processes in each work class 
is clearly desirable, if not an absolute necessity, and the 
ability to assign each process to a specific work class is 
obviously needed. 

To have two separate and independently-functioning mechanisms for 
classifying users into groups and limiting the number from each 
group that may be logged in concurrently Is at best unnecessary, 
and at worst, confusing and full of hidden problems. 

Therefore, there must be a close relationship between work 
classes and load control groups, and a single algorithm must be 
used to determine a process's membership in both classifications. 
For example, there could either be a one-to-one correspondence 
between work classes and load control groups, or else the work 
class of a process could be a function of its toad control group, 
with possibly more than one load control group belonging to one 
work class. Me have chosen the latter, more general, 
at ternat i ve. 
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It Mill be possible for the system administrator to specify the 
number of work classes (a limit of 16 will be imposed by the 
scheduler) t and the guaranteed percentage of each work class* 

The administrator Mill be able to define the membership of each 
work class* It Mill be possible to define such work classes ast 
all 10 daemons* the Backup daemon* ail users on a certain 
project* or one individual user* In each of those groupings* it 
will be possible to assign absentee and interactive processes 
either to the same or to different work classes* 

The set of work class parameters* and the membership of each Mill 
be able to be changed automatically Cat each shift change) and 
manually (by the system administrator* who may install a new 
table at any time)* Thus* the work classes of existing processes 
can change* 

HARDCORE SCHEDULER 



The new scheduler Mill maintain an eligible queue consisting of 

eligible processes only and Mill manage 16 ready queues* one for 

each Mork class* Each ready queue will be managed Just as the 

non-eligible portion of the current ready queue is managed — ■- 
that is the queues will each be internally sorted by ti values 

and favor the most interactive users within the Mork class* The 

current method of maintaining a ready queue is chosen for the new 
scheduler for three reasonsi 



1. It is response oriented* and in fact has been proven to 
provide the minimum mean respose time. 

2* If such a queue consists of processes all Mith ti = timax* 
the the queue is largely run as a pushdown stack* This 
leads to very desirable paging behavior in that the most 
recently run process (the process most likely to have its 
working set still in core or on the paging device* Mill 
often be the next process to be run* 

3* Use of already existing code Mill simplify the 
implementation effort required* 



To contain information pertaining to each Mork class* tc_data 
Mill contain 16 Mork.c I ass_tab le_entries (WCTE*s). Each MCTE 
will contain a thread-Mord for accessing the members of the Mork 
class Mhlch are ready* and all parameters and metering data 
relating to the Mork class* This Mill include the total amount 
of virtual cpu time used by the Mork class* the total number of 
times eligibility Mas granted to a member* the fraction of 
virtual cpu time Mhich the work class is to receive* and the 
response time seen by its members* 
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The actual algorithm used to enforce the proper sharing of the 
cpu resource Mill be as follows* Imagine the existance of a 
systea virtual clock which increments as virtual time is used by 
non-idle processes. Imagine also that each work class has a 
store of credits (in units of microseconds) which is continually 
growing at a rate proportional to the speed of the virtual clock 
multiplied by the fraction of cpu resources which the work class 
is to receive* Suppose further that the store of credits for the 
work class is decremented as members actually consume virtual cpu 
time. Clearly it is undesirable to allow credits to build up 
indefinitely for a work class with no processes ready, so a 
maximum value is set on the number of credits which can be 
accumulated. In addition the value is restricted from ever 
becoming negative. The algorithm for choslng the next work class 
from which to choose a process to which to award eligibility may 
then be as simple as choosing that work class which has 
accumulated the maximum number of credits. 

A worthwhile refinement would be to choose the work class for 
which the ratio of the number of credits to the quantum to be 
awaroed <ie. to the top member of the given ready queue) is a 
maximum. This tends to favor the prompt scheduling of the most 
interactive users across all work classes. It does not cause 
non-interactive work classes to fall far behind since eventually 
the interactive work classes choke off* This is because they are 
temporarily using credits faster than they are gaining them, and 
will eventually have a ratio which is arbitrarily low - — and not 
be chosen. 

It follows that the maximum build up of credits to be allowed 
must be greater than the maximum quantum allowed. It should 
probably be at least double that amount. 

The computation required for such an algorithm will amount to 
about 300 microseconds per eligibility granted* less if fewer 
than 16 work classes are defined. If eligibility Is awarded 10 
times per second (a high figure) on a one cpu configuration* the 
loss in system throughput may be about .33C. This is somewhat 
reduced by the fact that all sorting operations into the ready 
queue will be replaced by sorts into shorter queues. 



HARDCORE INTERFACE 

The interfaces to the hardcore scheduler will be the following* 

1. A gate to define Cor redefine) the set of work classes and 
their guaranteed percentages of cpu time. This gate is 
tentatively called hphcs_$def ine_work_c I asses. The target 
of this gate will be a new procedure (tcpli) which will 
check the consistency of its arguments* use existing 
subroutines to wire and mask* and lock the APT before 
modifying the work class table. Because this procedure will 
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not be heavily used it Mill call wire_proc$wire_me rather 
than being permanently wired* It will be illegal to 
undefine a work class that currently has processes in it* 
If that is attempted* the processld and work class number of 
one of the "offending" processes will be returned, in order 
that appropriate action can be taken* 

2* A gate to reassign one existing process to a different work 
class* It will refuse to change the work class if the new 
one is not defined* It is tentatively called 
hphcs_Jset_process_work_cl ass. The target of this gate will 
be pxss$set_work_c I ass* 

3* An additional parameter in the create_info structure passed 
to hphcs_$create_proc* the initial work class. It will be 
illegal to specify a work class that is not defined. It 
will be necessary for act_proc, the target of 
hphcs_$create_proc, to call pxss$set_work_c I ass, to insure 
that the work class being assigned to the new process 
currently exists* 

A primitive to simultaneously redefine the work classes and 
reset the wsrk class of each process is neither required by 
logical considerations nor Justified by efficiency 
considerations* Furthermore such a primitive would not be able 
to handle an arbitrarily large number of processes* 

In order to redefine the work classes in the general case, it 
will be necessary first to define a transitional set of work 
classes and percentages (including both old and new work 
classes), then to reset the work class of each process to the 
new value, and finally to define the new set of work classes* A 
procedure to do this will be implemented in the answering 
service* 

SUHHARY OF CURRENT LOAD CONTROL SOFTWARE 

Since work class membership will be a function of load control 
group membership, work class definitions will be stored in the 
NGT, and the implementation of the answering service and 
administrator interface to the priority scheduler will consist 
mainly of modifications to the current load control software, a 
summary of that software, as it now exists, is presented here* 

Load control group membership is specified in the SAT entry for 
each project. In addition, each project's SAT entry contains an 
absolute max user figure for that project that is enforced 
Independently of the load control grojp limits* 

Absentee and daemon processes are not subject to load control* 
They are always logged in on request. They are assigned to the 
load control group corresponding to their projects, but their 
group membership is ignored by everyone* 
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Load control groups are defined In the m as ter_group_t ab I e (MGT)* 
which Is a binary table maintained by an editor (ed_mgt), and is 
not subject to the install ui sci p i ir.e. it) This table contains 
limit parameters for each group* set by the system administrator* 
and it is also used to hold current load figures for each group, 
during a session. 

The group limits are defined in units of user Height* rather than 
number of users* (There are* however* limits in units of users* 
for the system as a whole* and for each project*) By default* 
each user has a weight of 10* so max_units is ten times 
max_users. Height is a function of the process overseer* and is 
determined by an array of weights kept in the SAT header* 

There are two sets of limit parameters per group* one used to 
compute primary_max_uni ts» the other* to compute 

absol ute_max_units. Each set contains three parameters! a 
constant (which may be zero)* and a numerator and denominator of 
a fraction* The formula for absolute_max_unlts for a group ist 

absol ute_max_units = absolute_constant * 

(aval I ab I e_max_units*absolut enumerator) /abso I ute_ denominator 

where aval I ab I e_max_ur.it s is the sy s t e m_ma x_un its less the units 
used by the absentee and daemon processes who are not subject to 
load control* The formula for primary_max_unl ts is the same, but 
using primary_const ant * primary_numerator* and 

primary_denominator. 

These calculations are performed for all groups each time a user 
attempts to log in* so changes to units used by absentee or 
daemons* changes to system_max_units* or changes in the HGT made 
by the system administrator are all taken into account 
immediately* 

The sys t em_max_unl t s figure is eithert 

1. taken from the SAT header* for a special session* or 

2* set by the operator* using the maxu command* in which case 
automatic maxunits setting is turned off* or 

3* set automatically at each shift change and whenever the maxu 
auto command is given by the operator* The automatic setting 
looks up the current shift and configuration in the config 
array in instal lat ion_parms» and chooses the corresponding 



(1) The install discipline is a method used for installing 
certain critical tables* whereby the Answering Service installs 
the table* when requested by a system or project administrator* 
ensuring that the Answering Service will not attempt to reference 
the table while it is being updated. 
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values for: sys tem_max_units, max_absentee_users» 

max_absentee_queue* and response_hlgh and response^! on* (The 
latter two figures are used by the load leveler (when it is 
enabled by the raaxu level command), which readjusts 
system_max_uni ts at every i5-minute accounting update, to 
keep response between the high and low figures*) 

The load control decision is rather complex, when special 
privileges like guaranteed login, the nobump attribute, and 
protection from preemption for a specified grace time are taken 
into account* But basically, if the system is full (as measured 
by system_raax_units or system_raax_users) then someone must be 
bumped or else the user is refused login* If the system is not 
full, but the group or the project is full (as measured by the 
group's absol ute_max_uni ts or the project's raax__users) , then 
someone in the group or project must be bumped, or else the user 
is refused login* If the group's primary_max_units are all 
allocated but its abso lute_max_units are not, then the user is 
logged in as a secondary user, subject to preemption* Secondary 
users (in any group) are the first to be bumped (oldest first) 
when some primary user wants to log in, f ol lowed by primary users 
(in the same group) whose grace time has expired, followed by 
practically anybody, when a user with the guaranteed login 
attribute is trying to log in* 

The load control group membership of a process never changes, but 
both the proportion of the aval lable_max_uni ts that each group 
gets, and the number Itself, can vary with the 
aval I abl e_max_unlts (which varies with shift, configuration, and 
absentee and daemon load), because of the max_units formula 
described above* 

NEW ANSWERING SERVICE ANO ADMINISTRATOR INTERFACE 

The HGT will be reformatted to hold work class definitions as 
well as load control group definitions* Since there will be a 
maximum of 16 work classes, but there is currently no restriction 
on the number of load control groups, the new HGT will consist of 
a header, followed by a fixed- length array of 16 work class 
definitions, followed by a variable-length array of load control 
group definitions* The header and the load control group 
definitions will remain essentially unchanged, except that each 
load control group definition will contain two additional 
8-element arrays, specifying the work classes to which 
interactive and absentee users in that load control group belong 
on each shift* 

One or more load control groups can belong to each work class* 
The max.users and max_units figures for each work class will be 
the sum of the corresponding figures for the load control groups 
that make up the work class* The work class maxima will not 
actually be computed and stored anywhere by the answering 
service, but they will be displayed by ed_mgt to assist the 
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system administrator In assigning reasonably consistent 
percentages to the work classes and max user and unit figures to 
the load control groups. The normal operation of load control § 
as described above* will limit the number of processes In each 
work class* 

The ed_mgt command will be modified to be able to store and 
modify the work class parameters. to verify, on request* the 
correctness* reasonableness* and consistency of work class 
parameters and the corresponding load control group definitions* 
and to print work class definitions and a cross reference showing 
the correspondence between load control groups and work classes* 
The changes to ed_mgt are described in detail in a later section* 

The Install command will be modified (and a new procedure* 
up_mgt_* will be written) so that the HGT can be installed while 
the system is up and users are logged in* up_mgt_ will have to* 
in general* reset the work class of all existing processes to the 
work class specified in the newly-installed HGT* 

The answer table (and daemon and absentee user tables)* and the 
create_lnfo structure passed to hphcs_$cr eate_proc* will have a 
new variable* work_class» added* 

I oad_ct I _$l oad_ct l_init will call hphcs_$def lne_work_c I asses* to 
define the work classes to be used by the scheduler* during 
answering service initialization* (This call must be made before 
the daemons are logged in*) 

I oad_ct I _$set_maxunlts* which is called at each shift change (as 
well as during the second half of answering service 
initialization* and whenever the operator command "maxu auto" is 
given) wilt redefine the work classes* as specifed for the 
current shift in the HGT* and will reset the work class of each 
existing process as required. 

Since the function of redefining the current work classes and 
resetting the work classes of all existing processes must be 
performed both at shift change and whenever a new MGT is 
installed* it will be implemented as a separate procedure* called 
in both situations* 

To support the assignment of work classes on the basis of person 
as well as project* the SAT and POT* and the procedures which 
compile* edit* and install them* will be modified to allow a load 
control group to be specified for an individual user rather than 
Just for a whole project* 

A new attribute* igroup (Individual group)* will be created. When 
that attribute is on in the SAT entry for a project* it permits 
the load control group for users on that project to be specified 
in the POT entry for any user on that project. (If that attribute 
is not on in the SAT entry, then all users on the project will 
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continue to belong to the load control group specified in the 
project's SAT entry.) When the igroup attribute is on in the POT 
entry for an individual user, it indicates that a load control 
group is specified in that user's POT entry. (If igroup is not 
on in a user's POT entry, that user Mill continue to be a member 
of the load control group specified in the project's SAT entry.) 
The naaie of the individual user's load control group will be 
stored in a presently unused pad field in the POT entry. This, 
plus the use of igroup in the POT entry as a positive indication 
that a group is specified, Mill allow this change to be installed 
without requiring that any existing POT's be reformatted or 
reinstal led. 

Ig_ctl_ Mill be nodified to assign a load control group on the 
basis of person as well as project, as described above. 

load_ctl_ Mill be modified to use the load control group of each 
process to assign it to the work class specified in the MGT for 
absentee or interactive users in that group, on the current 
shift. (Oaemon processes Mill be treated as interactive, for the 
purpose of work class assignment.) The assigned work class will 
be stored in the ansMer table (or absentee or daemon user table) 
entry for the process. 



cpg_ Mill copy the work class from the answer table entry into 
the create.info structure, before calling hphcs_Jcreate_proc. 

INSTALLATION PROCEDURE 

The hardcore system containing the priority scheduler, and the 
answering service containing the above modifications, can be 
installed in either order. If hphcs_$def ine_work_cl asses is not 
called, a single work class (work class 1> will exist by default, 
and will have a percentage of 10OZ. The version number of the 
create info structure will allow act_proc (the ring zero 
procedure called via hphcs_$create_proc) to determine if the new 
version, containing the work class, has been passed. If the old 
version of create_info is used, act_proc will assign processes to 
work class 1 by default. This allows the hardcore system to be 
installed first. 

The new ansMering service Mill check for the old format MGT, and 
if it is found* none of the new gates will be called, and every 
process Mill be assigned to work class 1, independent of their 
load control group membership. Further, a switch in the 
reformatted MGT, settable by ed_mgt» Mill allow this mode of 
operation to be specified by the system administrator after the 
MGT is reformatted. Finally, a check for the existence of 
hphcs_$def ine_work_cl asses will be made during ansMering service 
initialization, and if it is not present, the old mode of 
operation Mill be used. This Mill make the new answering service 
compatible with older system tapes. It will also cause the 
system to run as it does now, with only one work class, when both 



Page 10 



MT8-193 



the new answering service and the new hardcore system are 
Installed* The new scheduler will not be turned on until the MGT 
is reformat t6d» and the system administrator explicitly enables 
it* 

The system administrator will* of course* be Informed of all this 
in release documentation* The first time he uses the new ed_mgt* 
it will recognize the old format H6T* reformat It automatically* 
define a single work class (work class i) with a percentage of 
100%* make all load control groups members of It* and then invite 
the system administrator to define more work classes and reassign 
the load control groups to them* It will not be required that 
the administrator do so* but ed_mgt will keep reminding him* 
every time he uses it* until he does* 

Since the MGT will now be subject to the install discipline* the 
reformatted copy can not be put back in >scl* Hhen the M w" 
request is given* the reformatted MGT (named MGT.mgt) will be 
written in the working directory of the administrator (which 
should be >udd>sa>admln) • The administrator will be told about 
this by ed.mgt* Except for the instance when the MGT is 
reformatted, the edited HGT will be written back into the Input 
HGT* as is done now* However* the system administrator will not 
be editing the >sci copy any more* As a convenience* after 
writing the edited copy back into the original* ed_mgt will 
always ask "Install?"* and if the answer is yes* it will invoke 
the install command* The administrator will of course be able to 
invoke it directly* 

The installation procedures described above wilt make testing and 
initial installation of the system very convenient* and it will 
also allow the system administrator at each customer site to turn 
on the priority scheduler at his convenience* instead of forcing 
him to define some (possibly Ill-considered) work classes* Just 
to get the new system release to run. 

CHANGES TO ed_mgt 

Summary of Current ed_mgt 

The following summary describes only those features that are 
being changed* The HGT* as seen by a user of ed_mgt* is an array 
of load control group definitions* The find (f) request positions 
the current pointer to the specified group* The next (n)* top 
(t)* and - (minus sign) requests move the current pointer forward 
or backward in the array* The change (c) request changes 
parameters of the current group* The print (p) request prints all 
Information about the current group* The pall (pa* p*) request 
prints all information about all groups* Only the find and change 
requests take arguments* Their formats are* 



find 
change 



<group name> 

<code> <new value> £<code> <new value> •••] * 
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where <code> is the name of the paraaeter to be changed* Typing 
these requests without arguments causes ed_mgt to prompt the user 
for then* The change request puts ed_mgt into the change 
subcommand, in which <code> <new value> pairs are accepted* The 
asterisk at the end of the line exits from the change subcommand 
and returns to ed_mgt request level* 

Summary of New Features 

The find request will be modified so that a <group name> 
consisting of one of the integers 1 through 16 will refer to the 
corresponding work class* 

The next* top, and - requests will be modified to print the name 
and type of the entry being pointed at after the pointer is 
moved* 

The change request will be modified so that the set of codes 
accepted will be different, depending on which type of entry 
(work class or load control group) the current pointer is 
pointing at* New codes and other arguments will be added, to 
allow parameters of work classes, and the work class membership 
of load control groups, to be edited* 

A new request, gtobal_change (gc), will be added, to allow the 
same (set of) change(s) to be made to all work classes or to all 
load control groups* 

A new request, verify (v), will be added, to request that ed_mgt 
check all the work-class-related parameters in the edited HGT, 
and report any errors or warnings that would be received if the 
NGT were to be installed* 

The print and pall requests will be changed to print the new 
parameters, and the pal I request wi 1 1 take arguments, requesting 
that all work classes, or all load control groups, or both, be 
printed, or that a cross reference of work classes and load 
control groups be printed* 

Detailed Descriptions of New Features 

Two new formats for the change request will be addedt 

change <code> £<shift specifications <one or more values> 

change <code> C<shift spec*>] <interact ivel absentee> <value(s)> 

The first is used when editing work class parameters; the second, 
while changing the work class membership of a load control group* 
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The following new <code>*s can be used in the above requests* 

percent ( pc 1 5 2) 
absentee tabs! 
defined (def) 
worked ass (mc) 

The first three are used with the first form of the change 
requestt to edit work class parameters. The fourth is used with 
the second form, to change the work class membership of a load 
control group* 

The format of the <shift spec i f icat ion> is the word "shift'* 
followed by a shift number or a range of shift numbers (two 
numbers separated by a hyphen* the second greater than the 
first) I 

shift <number>l <number>-<number> 

The shift specification is optional* If it is omitted* the 
default is a function of how many values are supplied* If one 
value is supplied* it Is assigned to all 8 shifts* If a list of 
values is supplied* they are assigned to shifts 0* 1* •••* 
respectively* and shifts for which values are not supplied are 
not changed* 

The following relationship exists between the shift specification 
and the list of values! when a range of shifts is specified* a 
single data value is expected* and is assigned to all shifts in 
that range? when a single shift is specified* one or more values 
may be supplied* and they are assigned to shifts* in order* 
starting with the specified shift* 

< interact ivel absentee> can bet 

interactive (lntl 
absentee (abs) 

This argument Is used when setting the work class of a load 
control group* Separate work classes may be specified for 
interactive and absentee processes in the load control group* on 
each shift* If this argument is omitted* but the work class 
value(s) are given* the default is interactive* 

The work class parameters "defined" and "absentee" can have 
values of "off" or "on" (or "0" or "1"). They are per-shift 
switches* that indicate respectively* whether the work class is 
defined on the given shift* and whether absentee processes are 
permitted in it on that shift* 
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The foritat of the gl obal_cbange request Mill bet 

gc <type> <arguments acceptable to the change request> 

where <type> can bet 

I oad_contro I _group (leg) 
work.c I ass (wc) 

The effect of this coaaand will be to make each change (specified 
by a change subcowaand) to all entries of the specified type* 

The format of the pall (print all) request will bet 

Pali <type> 

where <type> can bet 

load_control_group (leg) 
work_class (wc) 
cross_ref erence (ere f f xref) 

If <type> is omitted* the default will be to print all three sets 
of information. 



Examples! 

change X 10 • 

change X shift 0 10 10 10 10 10 10 iO 10 • 
change pet shift 0-7 10 • 

The above are equivalent ways of assigning 10% to the current 
work class on all shifts* 

change X shift l 50 % shift Z-k 30 . 

The above request is equivalent to the following two requests! 

change X shift 1 50 • 
change X shift 2-% 30 * 

c wc int shift l 3 wc shift 2-k int 2 wc abs 1 • 

The above sets the interactive work class of the current load 
control group to 3 on shift l and to 2 on shifts 2-**» and the 
absentee work class on all 8 shifts to l. Notice that the shift 
specification and the interactive! absentee indicator nay appear 
in either order* 

gc wc defined shift 0 off defined shift 5-7 off • 



The above will set all work classes to undefined except on shifts 
This would be useful at an installation where only shifts 
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were in use, to simplify the output of the print and pa I i 
commands, since information about undefined shifts is not 
printed* 

Note that, in the examples v a period is used to terminate the 
change request lines Instead of an asterisk* In the new ed_ragt, a 
period will be accepted for that function, in addition to an 
asterisk, for compatibility with other Muttics editors. 

The examples show all required arguments supplied on a single 
line* ed_mgt will prompt for missing values* The example above, 
in which the percents for shifts 1 and 2-** were changed, would 
look like this If the user typed only what was requested (! 
indicates prompting messages)! 

f type! 

change 
! codet 

X 

! shifts 
1 

! value(s)* 

50 

! codes 
% 

! shifts 

! values 
30 

! codes 



types 



